EC2 でリザーブドインスタンス（RI）と Savings Plans （SP）のどちらを選ぶべきか？基準とするための最強の比較表を作ってみた
コンバンハ、千葉（幸）です。
リザーブドインスタンス（以下「RI」）と Savings Plans （以下「SP」）は、どちらも一定期間の使用をコミットすることでディスカウントを受けられる仕組みです。
両者で共通する点もあれば、異なる点もあります。どちらを選択するべきか迷う機会が多いのではないでしょうか。両者の特性を理解し最適な選択をするために、比較表を作成してみましたのでぜひご参考ください。
なお、RI および SP の対象となる AWS サービスはいくつかありますが、今回は Amazon EC2 を対象にしたもののみを考えます。
RI と SP の要素の全体像
比較表を確認する前に、基本的な要素について押さえておきましょう。
RI の要素の全体像
スコープと提供クラスという考え方があることを押さえてください。購入の方法により割引率が異なる部分については「割引率 高」などのマークで表しています。
SP の要素の全体像
RI と比較して考慮する要素が減少しています。
特に右上の、RI においては「インスタンスの属性」としていた箇所が「コミットメント額」に置き換わっていることに注目してください。SP のタイプは 3 つありますが、SageMaker SP は EC2 には適用できないため今回は除外します。
今回取り上げる RI と SP の種類
RI における スコープとクラス、SP のタイプの組み合わせを考慮すると、以下のようになります。
RI と SP の比較表
2021/11/28修正
「価格改定への追従」について Savings Plans で「できる」としていましたが、ここで想定していたような追従ができる仕様はありませんでした。そのため「できない」に修正しています。詳細は以下をご参照ください。
2021/10/12修正
「アベイラビリティゾーン指定」「インスタンスサイズ指定」「キューイング（予約購入）」行に誤りがありました。以下のように「スタンダード/コンバーティブル」の区分けになるような記載をしていましたが、対象行は「リージョナル/ゾーン」の区分けで違いが出る項目です。
▲ 修正前の誤った図
RI と SP を比較したものがこちらです。別タブで画像のみ開くなどして、拡大してご参照ください。
補足事項として以下があります。
- コミットメント期間（1年、3年）と支払い方法（すべて前払い、一部前払い、前払いなし）に関しては RI と SP に差異がないため省略しています
- 青字で ✅ がついている項目が、他の種別と比較して優位性があるものです
- 「オンデマンドに対する割引率」は「高い」か「低い」かの２種類のみで、6種別を横断して同じ価格です
- EC2 Instance SP はスタンダード RI と同等の価格
- Compute SP はコンバーティブル RI と同等の価格
カラフルで目に優しくない、セル結合されているのが好みでない、などあると思いますので、別バージョンを末尾に用意しています。
RI と SP の比較表（CSV）
画像ではお手元で加工がしづらいかと思いますので、CSV 形式にしたものを載せておきます。スプレッドシートなどでお好みの形で改変してください。
,,Savings Plans,,リージョナル RI,,ゾーン RI, ,,EC2 Instanse SP,Compute SP,スタンダードRI,コンバーティブルRI,スタンダードRI,コンバーティブルRI 価格,オンデマンドに対する割引率,✔︎相対的に高い（最大72%）,相対的に低い（最大66%）,✔︎相対的に高い（最大72%）,相対的に低い（最大66%）,✔︎相対的に高い（最大72%）,相対的に低い（最大66%） インスタンスの属性,インスタンスファミリー指定,必要,✔︎不要,必要,必要,必要,必要 ,インスタンスサイズ指定,✔︎不要,✔︎不要,必要だが柔軟性あり,必要だが柔軟性あり,必要,必要 ,リージョン指定,必要,✔︎不要,必要,必要,必要,必要 ,AZ指定,✔︎不要,✔︎不要,✔︎不要,✔︎不要,必要,必要 ,プラットフォーム指定,✔︎不要,✔︎不要,必要,必要,必要,必要 ,テナンシー指定,✔︎不要,✔︎不要,必要,必要,必要,必要 特徴,キャパシティ予約,ODCRが必要,ODCRが必要,ODCRが必要,ODCRが必要,✔︎できる,✔︎できる ,マーケットプレイスでの購入/出品,できない,できない,✔︎できる,できない,✔︎できる,できない ,購入後の交換,できない,できない,できない,✔︎できる,できない,✔︎できる ,Lambda・Fargateなどへの適用,できない,✔︎できる,できない,できない,できない,できない 運用,購入時のコミット金額換算,必要,必要,✔︎不要,✔︎不要,✔︎不要,✔︎不要 ,購入後の変更,できない,できない,✔︎一部属性でできる,✔︎一部属性でできる,✔︎一部属性でできる,✔︎一部属性でできる ,キューイング（予約）,✔︎できる,✔︎できる,✔︎できる,✔︎できる,できない,できない ,価格改定への追従,できない,できない,できない,✔︎交換によりできる,できない,✔︎交換によりできる ,有効期限切れ前の通知,✔︎できる,✔︎できる,✔︎できる,✔︎できる,✔︎できる,✔︎できる
RI と SP の何が違うのか
RI と SP で明確に異なる点は、購入時の指定の仕方です。
RI も SP も「条件に合致したインスタンスのオンデマンド料金を相殺できる権利を、オンデマンドより安い価格で購入する」という考え方をするとイメージしやすいかと思います。
RI の場合は、条件に合致するインスタンスの様々な属性を指定して購入します。スコープやクラスにより細かい違いがあるものの、ある程度具体的にインスタンスの属性を指定する必要があります。プラットフォーム、インスタンスタイプなど指定した条件から外れるインスタンスがあった場合、権利が適用されず購入した RI が無駄になる、という事象も起こり得ます。
一方で SP の場合は条件に合致するインスタンスに相当する金額を自分で計算し、その額をコミットします。これもタイプにより違いはありますが、条件の指定が緩く、幅広いインスタンスに対して最も割引効率が高くなるように自動で適用されます。
RI と SP のメリット・デメリット
SP のメリット
SP が優位となるのは適用対象となるインスタンスの柔軟性です。この部分は比較表の「インスタンスの属性」部を参照してください。多くの属性で「不要」となっていることが見て取れるかと思います。
「不要」ということはつまり、適用対象となるかどうかの条件に含まれないということです。インスタンスサイズを途中で変更しても、Windows や Linux といったプラットフォームを変更しても、それによって適用対象でなくなるということはありません。
構成が確定しておらず変更が見込まれる場合には、この柔軟性は大きなメリットとなるでしょう。
SP のデメリット
一方で、SP では全て金額に均してから購入する必要があるため、金額換算自体に手間がかかることに加え、どの対象への適用を想定したかが分かりづらくなるというデメリットがあります。RI であれば購入履歴をマネジメントコンソールから参照すれば適用を想定する対象の属性が一目瞭然ですが、SP ではコミットメント額が見えるだけです。
1 年単位、3年単位で購入をし直す運用をしている場合には、担当者の変更なども踏まえ別途資料を手元に用意しておかないと、コミットメント額の算出基準が分からなくなるということに繋がりかねません。逆に言えば、そこをカバーできるのであればあえて RI を採用するケースはグッと少なくなるのではと考えています。
RI と SP の各種別ごとの比較
冒頭の比較表では 6 種別まとめての比較でしたので、それぞれの切り口での比較を行います。
リージョナル RI とゾーン RI の比較
RI のスコープの違いです。料金は両者で変わりありません。大きな違いはゾーン RI にキャパシティ予約の機能があることです。
EC2 インスタンスを新規作成する・あるいは停止状態から起動させる際に、AWS 側に十分なオンデマンドキャパシティがなくエラーが発生することがあります。キャパシティ予約を行うことでそのエラーの発生を抑制できます。
RI/SP の中でキャパシティ予約の機能を持つのはゾーン RI のみです。しかし、それ以外の種別を使用する場合にもオンデマンドキャパシティ予約（ODCR）と呼ばれる別のリソースと組み合わせることでキャパシティ予約を実現できます。
また、ゾーン RI を使用する場合はインスタンスサイズの柔軟性がないため、購入時に指定したインスタンスタイプのサイズを変更すると適用対象外となることに注意してください。
（リージョナル RI の場合であればどんな場合でも柔軟性があるというわけではなく、共有テナンシーでプラットフォームが Linux であること、といった条件があります。詳細は最新の上記ドキュメントを参照してください。）
スタンダード RI とコンバーティブル RI の比較
RI の提供クラスの違いです。スタンダード RI の方が割引率が高く、マーケットプレイスの利用が可能です。
どちらのクラスでも、一部属性の変更は可能です。変更可能な属性の例として以下があります。
- 同じリージョン内で AZ を変更する（ゾーン RI の場合）
- リージョナル RI と ゾーン RI を変更する
- 同じインスタンスファミリー内でインスタンスサイズを変更する（Linux/UNIXのみ）
変更可能な属性はそこまで多くありません。詳細については以下を参照してください。
「変更」できない属性も、交換により変えられるものがあります。コンバーティブル RI でのみ交換が可能です。
交換を行う上で最も考慮すべき点は、「交換後の RI が交換前の RI と同等以上の価値となること」が必要な点です。インスタンスサイズを小さいものに交換する場合には、そのぶん数を増やすといった調整が必要です。交換後の方が高額な場合には差額を支払う形となります。
前払いあり→前払いなしの支払い方法の交換ができないなどいくつか注意点があります。詳細は以下を参照してください。
EC2 Instance SP と Compute SP の比較
SP の中でのタイプの違いです。どちらのタイプも RI と比較してインスタンスの属性の指定が緩いことがわかります。
Compute SP は EC2 Instance SP と比較して割引率が低い分、インスタンスファミリーおよびリージョンの指定も不要となり、Lambda や Fargate といった EC2 以外の AWS サービスのリソースも適用対象となります。
SP がどういった優先順位で適用されるかについて、大まかに以下の通りとなります。
- 同じ条件に合致する RI が存在した場合、RI が優先される
- 同じ条件に合致する EC2 Instance SP と Compute SP が存在した場合、EC2 Instanse SP が優先される
- 同じ条件の SP においては、割引率が高い対象への適用が優先される
「割引率が高い対象への適用が優先」について極端な例を用いて補足します。
| 割引率 | オンデマンド料金 | コミットメント額 | |
|---|---|---|---|
| インスタンスA | 90 % | 100.0 USD | 10.0 USD |
| インスタンスB | 20 % | 12.5 USD | 10.0 USD |
インスタンス 1 台分のオンデマンド料金を相殺するために必要なコミットメント額が 10 USD のケースを考えます。コミットメント額 10 USD 分の SP を保有している場合に、割引率が低いインスタンス B に適用されてしまうと大きな損となります。インスタンス A のオンデマンド料金 100 USD がそのまま発生するためです。
実際にはここまで極端な数字の開きはあり得ませんが、割引率が高い方に自動的に適用されることによるメリットはイメージがついていただいたかと思います。プラットフォームやインスタンスサイズなど割引率に影響する要素は多々ありますが、その中でも最も効率が良い対象に適用してくれるのは魅力ですね。
SP の適用の順序の詳細については以下を参照してください。
あらためて RI と SP の比較
各種別での比較が終わったところで、あらためて全体での比較を載せておきます。
一部の項目について説明できていないためここで補足します。
キューイング（予約購入）
キャパシティ予約の機能を持つゾーン RI のみ、予約購入ができません。以前は SP も対応していませんでしたが、2020年9月に対応しました。
有効期限切れ前の通知
こちらも以前は SP で対応していませんでしたが、2020年11月に対応しました。運用を考えると助かる機能です。
価格改定への追従
ここでの価格改定とはオンデマンド料金の値下げを指しています。オンデマンド料金の値下げは、過去に何度か行われています。
RI の場合は購入時点の価格体系が維持されるため、その後にオンデマンドの価格改定があると相対的に割引率が下がることになります。再びかなり極端な例ですが、以下のような価格改定があったとします。
| 改訂前 | 改定後 | |
|---|---|---|
| オンデマンド | 20 USD | 18 USD |
| RI | 15 USD | 13 USD |
15 USD で RI を購入し、その後にオンデマンド料金の価格改定があったとします。前払いなし/ありの支払い種別によらず、購入済みの RI の価格が 15 USD というのは価格改定後も変わりません。
当初はオンデマンドに対して 5 USD 分の割引の幅があった分が、改定後は 3 USD 幅に減少するため、相対的に割引率が低下しています。価格改定後に RI を購入していれば 13 USD で済んでいたため、そのぶん損が発生していると考えることもできます。
コンバーティブル RI の場合は、購入済みの RI を新しい価格の RI に交換できます。（今回の例では 15 USD から 13 USD に交換できる。）しかし、「同等以上の価値となる場合にのみ交換可能」という制約があるため、そのぶん数を増やすといった調整が必要になります。
2021/11/28修正
SP の場合は コミットメント額での指定となりますので、上記のような「相対的な割引率の低下」といった点を考慮する必要がありません。 、SP 登場後にオンデマンドの価格改定の実績がありません。オンデマンドの値下げに伴い SP も値下げされるかは不明です。少なくとも、SP の料金の改定があった場合でも購入済みの価格レートは維持されます。詳細は以下を参照してください。
終わりに
EC2 の RI と SP を比較してみました。パラメータと言うのか、考慮すべき項目が多いため「どちらが良いのか」を判断するのは難しいかと思います。本エントリでは一通りの項目を洗い出したため、選定の判断をする手助けになっていれば幸いです。
個人的には SP の選択を優先して検討することをお勧めします。インスタンスの属性の指定に柔軟性があるため、「意図せず適用対象から外れていた」という事象が起こりづらい点が魅力的です。
RI でしかできない点に大きなモチベーションがある場合には、他の手段で代替できないか検討の上、特性を理解したてご選択いただければと思います。
以上、 チバユキ (@batchicchi) がお送りしました。
参考
- Reserved Instances - Amazon Elastic Compute Cloud
- What are Savings Plans? - Savings Plans
- On-Demand Capacity Reservations - Amazon Elastic Compute Cloud
- 本文は長いけどわかりやすい（はず）AWSコスト削減の要 -RIとSPパーフェクトマスター 2020- | DevelopersIO
- AWS Black Belt Online Seminar 2017 AWS のコスト最適化 リザーブドインスタンス
- 2017年の資料のため情報が古くなっている箇所があります
- 考え方の参考にするにとどめ、最新情報はドキュメントを参照してください
RI とSP の比較表の別バージョン
RI と SP の比較表：モノクロバージョン
RI と SP の比較表：結合なしバージョン
RI と SP の比較表：モノクロ結合なしバージョン
